An inclusive decision in a business process model is a decision that can go to multiple output branches (i.e., paths) of a process simultaneously. For example, there are four possibilities associated with a result of an inclusive decision having two output paths: (1) none of the two paths are activated; (2) the first path only is activated; (3) the second path only is activated; or (4) both paths are activated simultaneously. In conventional business process modeling, due to resource allocation and resource availability factors, there is no general technique for identifying which of the multiple output branches of an inclusive decision will last the longest. This difficulty in identifying which branch from an inclusive decision will last the longest interferes with waiting for all activated output branches to finish before proceeding to the next step in the process and creates a problem for the placement of stop nodes, which are required for successfully simulating the process. If two paths from an inclusive decision run simultaneously, the path that finishes first will cause the process to terminate before the other still running path finishes, thereby causing the process instance to fail. Reconstructing the inclusive decision as a merge node (i.e., a modeling element that waits for any incoming path to the merge node to finish processing) followed by a stop node or as a join node (i.e., a modeling element that waits for all incoming paths to the join node to finish processing, regardless of whether the path is activated or not activated) followed by a stop node is deficient because it does not provide the behavior of waiting specifically for all activated paths to finish processing. Further, the outputs of the parallel paths from an inclusive decision are not necessarily of the same data type and the conventional reconstruction schemes described above using a merge node or a join node cannot work with branches having outputs of different data types. Still further, creating a task with a single input criterion to synchronize flows does not yield a desired result because of the newly created task's limitation of starting only if all the parallel paths run simultaneously. Further yet, creating a task with multiple input criteria leads to undesirable ambiguous results in which the task is instantiated multiple times. For the example in which the inclusive decision has two output branches, a first input criterion with two inputs handles the case in which the two paths run simultaneously, a second input criterion with the first input only handles the case in which the first path runs alone, and a third input criterion with the second input only handles the case in which the second path runs alone. The ambiguity in the result of this example arises when the two paths run simultaneously and in general, do not finish at the same time. In this scenario, two of the input sets are satisfied, thereby causing the newly created task to run twice and produce the output twice, which is not the required behavior. Thus, there exists a need to overcome at least one of the preceding deficiencies and limitations of the related art.